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Arbitrarily fine-grained limitation of access to information 
stored in a resource of a data processor network is provided 
in a manner compatible with existing network browsers by 
mapping user identity and credentials with randomly 
assigned security cookie information which thus serves as a 
surrogate credential accompanying each user request during 
a session. Labels are imbedded within HTML files/text 
which may embody any desired security policy, including 
mandatory access control (MAC) arrangements which are 
not available through native browser functions. Data is 
retrieved in response to a user request which includes a 
security cookie from a location in the resource which is not 
directly accessible through use of a URL; the location being 
stored in a configuration file which is hidden from users. The 
retrieved data is then filtered in accordance with labels 
provided for each page and/or embedded in the text and used 
to build a response which may include hypertext links or 
other user interfaces for transmission to the user. Provision 
is made for viewing or changing of labels, credentials and 
passwords. 
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TRUSTED SERVICES BROKER FOR WEB 
PAGE FINE-GRAINED SECURITY 
LABELING 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention generally relates to computer net- 
works including shared resources and, more particularly, to 
computer networks selectively providing access to informa- 
tion to a plurality of users through a web browser/server 
interface in accordance with user credentials. 

2. Description of the Prior Art 

With the growing familiarity and ubiquity of the Internet 
and World Wide Web for exchange of information, similarly 
styled and functioning information exchange systems are 
being provided on more or less private intranet (e.g. within 
a business or organization) and extranet (among a select 
group of cooperating businesses or organizations) network 
systems for exchange of data among, for example, employ- 
ees of an organization or company connected thereto. The 
familiarity of users with internet browsers enhances their 
efficiency and comfort with using systems which operate 
similarly and provide similar interfaces in intranet and 
extranet communication systems in their workplaces. 

Such systems can employ firewalls, virtual private net- 
work technology, or other technologies to limit access to 
computing resources to some subset of users, and thus 
completely deny access to others. On the other hand, some 
computing resources are openly contactable by nearly every- 
one in an enterprise. In either case, there can be scenarios 
where only a subset of people who can contact a resource 
should be capable of accessing the information provided by 
the resource. This is true even of a situation where firewalls 
exist to create enclaves of users that have exclusive access 
to resources within their respective enclaves, because a 
resource may have to be placed in a common area so that 
selected individuals from multiple enclaves get appropriate 
access. 

When the computing resource is web information, most 
web servers provide for this additional security need by 
enforcing a user authentication, establishing a Discretionary 
Access Control (DAC) credential for the user, such as a 
group or a role, and then performing access control on 
HTML requests at either the directory or file level. However, 
there are situations where organizations either need special- 
ized web data access using Mandatory Access Control 
(MAC) which assigns data both classifications and 
compartments, or where organizations require that portions 
of individual HTML files be labeled such that only certain 
users see certain portions of the file. Such capabilities are not 
supported by native web server security. Nor arc they 
supported by other industry products that typically install 
middleware on clients and servers as the basis for the digital 
certificate or Kerberos ticket exchanges, so as to perform 
authentication and enforce access control to web and non- 
web network resources. For example, such products still 
provide a DAC access control mechanism, and any fine- 
grained labeling of objects is supported to a file level or data 
base record level, but labeling is not applied internally of 
ASCII files, such as static HTML pages. 

Several concepts are involved in known Internet, intranet 
and extranet arrangements which are exploited in a modified 
and enhanced form in the invention, known forms of which 
will now be discussed, A first concept is that of the Common 
Gateway Interface (CGI) and a second concept is that of the 
"cookie". 
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In regard to known CGIs, most web page access is 
performed using a so-called simple URL (an acronym for 
Universal Resource Locator) of the form 
"http://domain.com/dir/pag.html". 
5 This directs the web server, also known as the "httpd server", 
managing the web site domain "domain.com" to retrieve the 
static HTML page "pag.html" from a directory called "dir" 
that is, itself, a subdirectory of a single and well-known 
directory on the web server. 
io In contrast, a generalized URL invoking a CGI interface 
directs the web server to invoke another program, a CGI 
program, which builds the contents of the HTML page to be 
presented to the user in accordance with parameters pro- 
vided in a generalized URL (hereinafter sometimes "CGI 
is URL" to indicate this function in the context of the 
invention). Essentially a CGI program is a stateless interface 
which executes, when invoked and utilizing parameters 
provided in the "CGI URL", to provide a single service to 
the network user. Generalized URLs for performing such a 
20 function are more complex and of the form 

"http://domain.com/cgi-bin/program/extrapath/parmlo 
value l&parmN=valueN". Such a URL tells the web 
server to execute the CGI program "program", provid- 
ing additional path information as specified by "extra- 
25 path" and providing any desired number of parameter 
values (e.g. parml and pannN) to the CGI program. 
The CGI program then executes and provides the 
result, in HTML format, which the browser can inter- 
pret and display. 
30 The concept of a "cookie" is an incident of the fact that 
CGI programs are stateless interfaces performing the func- 
tion of building a response each time invoked and, while 
uses of the CGI program may be logged, the result of the use 
is not. Generally the "cookie" facility allows the CGI 
35 program to maintain state for a browser session. The CGI is 
free to assign whatever kind of state it wants to a cookie 
value it assigns to a browser and could be considered as 
providing browser session identity (but not necessarily user 
identity). 

40 A "cookie" name and value get assigned to a browser for 
a specific web server domain. This occurs when a CGI script 
assigns a cookie name and value into the Hypertext Transfer 
Protocol (HTTP) header portion of the HTML reply that is 
sent back to the browser. The cookie name and value are 

45 then echoed back to the web server at the identified domain 
whenever the browser issues another HTTP request to the 
web server. Thus, the cookie name and value are present at 
both the web browser and web server. The server can 
continue to set different values, or set new cookie names, as 

50 it desires. This cookie data thus provides a means of having 
the web server maintain and recognize state information 
across multiple client requests. Cookies are also assigned 
lifetimes by the web server; if finite, the cookie name and 
value are stored in a disk file at the browser, tied to the 

55 domain name. If no expiration is specified, cookies only live 
in browser memory (but not on disk), and are in effect for 
only as long as the browser is not terminated. 

A "cookie" value is assigned by a CGI script and is unique 
to the domain. As is known in the art, the "cookie" is a 

60 passive (in at least the sense that the user has no control over 
its content) group of data, generally randomly assigned and 
may be stored in a file at the user's browser (in connection 
with assignment of a lifetime parameter). The "cookie" 
value, once assigned, can then be sent to the client browser 

65 by the web server. The client browser then returns it with 
each transaction requested during the session. Thus, the 
cookie is available at both the domain and the web server for 
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each transaction in tbe session and can associate the trans- description of a preferred embodiment of tbe invention with 

actions in the session with a particular domain. reference to the drawings, in which: 

It should be noted that neither CGI programs nor cookies, p IG x is a hign _ level block diagram of the system 

as presently known and used m the art, have any security arcbiteclurc of known i ntcrnet . style communication 

.mpl.cat.ons. The cookie merely allows a web server to, at 5 arrangemcnls woich ^ also em pi oye / m , he mvention> 

most, infer information about what occurred on previous & y J ' 

transactions from the browser. Strictly speaking, even this is FIG - 2 * a flow chart/high-level block diagram of the 

not necessarily true, if a user alters the cookie value as stored Getpage function in accordance with the invention, 

in the disk cookie file. Such an act does not actually defeat FIG. 3 is a flow chart/high-level block diagram of the 

or "spoof security aspects of the server, although it can 1Q Authenticate function in accordance with the invention, 

make the web server act differently In fact, cookie names FIG. 4 illustrates the architecture of the invention, includ- 

and values can never be used as the basis for providing . ^ ^ ^ of HG x aQd showi dala flow 

secunty features, unless they are utterly hidden from users, for authenticalion and fiUeri and * induding the 

to prevent cookie inspection or alteration. ~ . , A . *. & c . & _ „ T ^„ _ 5 _ - 

r r Getpage and Authentication functions of FIGS. 2 and 3, 

SUMMARY OF THE INVENTION 3S respectively, 

It is therefore an object of the present invention to provide FIG. 5 is a flow chart/high-level block diagram of the 

a web server "filtering" security service that is flexible in View Credentials function in accordance with the invention, 

regard to the underlying access control policy, and is fine- FIG. 6 is a flow chart/high-level block diagram of the 

grained m the Ch Credentials fonctio|1 in accordanc * with the 

files may be labeled such that the filtering will excise the 2 o invention 

data upon return to the browser if the user is not authorized ' 

to see the data in accordance with that label. FIG - 7 * a flow chart/high-level block diagram of the 

It is another object of the invention to provide the service P«ssw°k1 form function in accordance with the invention, 

by limiting installation of invention items to web server FIG - 8 ^ a flow chart/high-level block diagram of the 

machines, avoiding the need to install anything on web 2 5 Chan S e Password function in accordance with the invention, 

browser clients. FIG. 9 illustrates the architecture of the invention, as also 

It is a further object of tbe invention to provide, in a shown in FIG. 4 and showing the data flow for credential/ 

manner transparent to a user (subsequent to entry and Password operations and including the View Credentials, 

acceptance of the user's credentials), access to information Change Credentials, password form and change password 

which is filtered for presentation to the user in accordance 30 functions of FIGS. 5, 6, 7 and 8, respectively, 

with access authorizations corresponding to the user. FIG. 10 is a flow chart/high-level block diagram of the 

It is yet another object of the invention to provide a View Label function in accordance with the invention, 

convenient arrangement for changing credentials, viewing FIG. 11 is a flow chart/high-level block diagram of the 

and changing of fine-grained labels, changing of passwords Change Label function in accordance with the invention, 

and ensuring a logout function. 35 mQ n {s a flow chart/high _ level block ^ &am of the 

It is another further object of the invention to enhance j^g^t function in accordance with the invention, and 

known web server functions by supporting user authentica- CTO t* -n * . *i. L \, c 

*u u r>r-i • * * w aV. jt^a^ j 1 FIG. 13 illustrates the architecture of the invention, as 

tion through CGI scripts, to map MAC and DAC credentials , , . ™~ A , u . 4U . 4 a ' 

u a ■* i u 1 ' 4 l- ttt-wt c i j a lso shown in FIG. 4 and showing the data flow for 

to users, embed secunty labels within HTML files and * u j n<* i ij- ^ti_i 

provide for changes of password, labels, credentials, MAC 40 ^'hen t.cal.on and page f.ltenng .and I .nclud.ng the Label and 

ranges and/or DAC role lists. J^""' °P erallons functlons of FIGS - 10 ' 11 and 12 > res P ec " 

In order to accomplish these and other objects of the 

invention, a method of limiting access to information stored DETAILED DESCRIPTION OF A PREFERRED 

in HTML files accessible by a web server through a CGI EMBODIMENT OF THE INVENTION 

script, in which the information includes HTML label stoic- 45 

tures recognizable by the CGI script, is provided which Referring now to the drawings, and more particularly to 

comprising the steps of dynamically storing at a web server FIG \ X ' there IS shown a hl S h " lev el schematic diagram of the 

a mapping of a web cookie value to user credentials architecture 10 of a network system such as is found in 

retrieved from CGI accessible registry storage, to thereby mternet ' intranet and extranet applications. This portion of 

establish the web cookie as a security cookie in the mapping, 50 the system architecture will also be found in FIGS. 4, 9 and 

creating a set of the credentials by prompting a user for for 13 wh,ch arc llluslratlve of lh e architecture of the invention 

authentication information, validating the authentication and °P eratioQ s performed therein in accordance with the 

information against user information retrieved from the CGI 1Dv ention. Accordingly, the architecture of FIG. 1 will also 

accessible registry storage in response to a request for be common to the architecture of a portion of the invention 

retrieval of a stored HTML file that was not accompanied by 55 but, in regard to the invention, the content of data routed 

a web cookie name and value contained within said therethrough will be characteristically different from that 

mapping, retrieving the stored HTML file in response to a commonly used in the art. Further, FIG. 1 is arranged to 

request from a user accompanied by said security cookie facilitate an understanding of the invention and the compat- 

value, filtering the stored HTML file in accordance with the ability of the invention with currently known systems. 

user credentials associated with the security cookie value to <*0 Accordingly, no portion of FIG. 1 is admitted to be pnor art 

form filtered information in accordance with the HTML as t0 the P resent mventl0n be y° nd th e description of the 

label structures, and returning the filtered information to the operation of known systems which immediately follows. 

user. Specifically, in known systems a computer 20, such as a 

BRIEF DESCRIPTION OF THP nnAWiNir<5 personal computer (PC), will contain a web browser 30 of a 

BRIEF DESCRIPTION OF THE DRAWINGS 65 type an(J confine which fc nol i mporlant to the practice 

llie foregoing and other objects, aspects and advantages of the invention. The web browser 30 handles communica- 

will be better understood from the following detailed tions with a web server and cooperates with the computer 20 
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to present a display and other aspects of the network is maintained by a trusted administrator. Two parameters 

interface to the user. The computer 20 will also include some within the configuration data, document location and cookie 

form of interface 25 to a communication link or network 40. name, are particularly important and will be discussed in 

A modem would, for example, be an appropriate interface to detail below. In practice, however, a preferred form of the 

a network communicating over telephone lines or other 5 invention allows, as a perfecting feature, for one web server 

audio links. t0 mana g e several "virtual web sites", each with its own 

The communication link 40 will enable communication of un i que configuration and behavior. The CGI scripts imple- 

the web browser 30 with the web server or server 50 which menting the inve ntion determine which virtual web site is 

will thus respond to user inquiries or other control functions bei addressed by a cliem via the « ex trapath" information 

commumcatecL from the interface to the web server 50 by the ]Q ^ ^ of ^ {ncom - URL ^ fa a te 

browser 30. The web server 50 will communicate with its fi A , e u « * * i u •* » ^ j 

z *i i i j* i li.i ■ t r * configuration file for each virtual web site supported, 

storage (possibly including relational database interfaces to b , , iL , . . 

other machines through its CGI scripts) to assemble a d accordmg o the strwg value supplied in "extrap- 

response to be returned to the browser 30. ath " Mu,tl P le vlrtual web sl ! e * can be used to all ° w for ° ne 

A , . . . , t . r *^w« * .« web server to support two ditlerenl security needs without 

A typical session using the architecture of FIG. 1 wil , r 4U c • w i A n *• i 

i_ • .i. 4 i_ . t_i- l r > i i- ^ 15 me necessity of running multiple servers. Alternatively, this 

begin with the establishment or a network link 40 and the .-i * « — r i L •„ r j 

t & . - , , " . capability allows support of a virtual web site for demon- 

transmittal of a request to the web server 50. This may 4 ,. 

7. . , , stration or diagnostic purposes, 
include a communication protocol which may include a 

plurality of bidirectional transmissions including processing Regardless of whether one or multiple web sites are 
of a user name and password as stored at memory 70 over „ supported the two most important fields within any con- 
link 40. When the link is established, a web server may figuration file are: 

choose to set, or transfer, a "cookie" to the browser, and may 1- Document location— This information is provided in, 
in fact continually perform such "cookie" setting operations f° r example, a look-up table format and names another 
with different values as the session proceeds. As alluded to directory on the web server machine where the desired 
above, the "cookie" allows results of independent transac- 2$ document is located in secured HTML files. By storing in a 
tions which are part of the same user session to be associated unique location, users cannot use a simple URL for retriev- 
ing a larger session transaction. Individual purchases placed ing a secured web page, including any security labels it may 
into a "virtual shopping cart" would be an example of such contain. Security can thus not be bypassed using a simple 
a session transaction; the "cookie" associating the indepen- URL since the web server will look only in its own "well- 
dent transactions and allowing an aggregate summation or 3Q known repository" of unsecured HTML pages in response to 
totalization of the session transaction to be done. a simple URL. The provision for a unique location for 
Once the link has become established, one or more secured HTML pages also separates them from other virtual 
requests for information to retrieve HTML documents 80 or w . eb sites on tne which ma y label data differently in 
execution of CGI programs 90 to build such pages may be different directories. 

sent, serviced and the results returned in HTML format for 35 2. Cookie name — The basis for forcing user authentica- 

display to the user at computer 20 in the course of a session, tion and then binding a browser session to a user identity and 

The results may be aggregated in accordance with the associated credentials is the web "cookie" mechanism. Each 

"cookie" as alluded to above, if the server has chosen to use virtual web site must use a unique "cookie" name. Standard 

cookies. The session transaction, as tied together by the web browsers support a "cookie file" in which cookie values 

cookie, terminates once the client is no longer capable of 40 are assigned to cookie names for a particular domain when 

transmitting the cookie value to the web server on each web servers perform a special "set cookie" action. Once a 

individual transaction. cookie has been set, the browser sends it and any other 

This termination can occur in two ways depending on the cookie it may have for this web server's domain at each URL 

establishment of an expiration for the cookie by the web request. 

server. First, if there is no cookie expiration established by 45 Since the invention uses the value of the cookie as a 

the web server, the cookie is not permanently stored at the means for mapping user identity and credentials to that 

client; once the web browser is terminated, the cookie and, value, the cookie is thus effectively a surrogate credential for 

hence, the session are lost. Second, if there is a cookie the user in regard to the document locations which may be 

expiration established by the web server, the cookie and accessed. The "cookie" as employed in the invention will 

expiration time are stored on the web browser machine's 50 hereinafter be referred to as a "security cookie" to indicate 

disk. The session transaction thus holds across multiple the surrogate credential function and to differentiate the 

transactions and invocations and terminations of the web "cookie" as utilized in the invention from the functionality 

browser until the expiration time is reached. of "cookies" as previously known and used, even though the 

By way of introduction to the invention with the forego- security cookie can be accommodated by known systems, 
ing as background, the invention provides significant 55 Incidentally, it should be understood that the invention as 
enhancements to and different functionality of both the will be as described below is inconsistent with one common 
"cookie" and CGI interfaces, as described above. HTML feature known as "framing". Therefore, the follow- 
Specifically, the key to the solution of the problems of ing discussion assumes that no HTML "frame" statements 
providing fine-grained security while maintaining full com- are contained in the static information to which security 
patibility with present systems is provided in accordance 60 labels are to be applied in accordance with the invention, 
with the invention by ensuring that each web server is The preferred embodiment of the invention employs nine 
properly configured to exercise the function of a trusted "security CGI programs" (sometimes referred to hereinafter 
services broker (TSB) for the smallest divisions of data and as "security CGIs"; the term "security CGI" being used to 
the most subtle distinctions in access authorization that may differentiate the functions of the CGI scripts which support 
be desired. 65 me functions of the invention from the arbitrary CGI scripts 

The solution provided by the invention is implemented which may be programmed to perform arbitrary desired 

via CGI scripts under the control of configuration data which servicing of user requests). These nine security CGIs col- 
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lectively constitute a "trusted services broker" as applied to stored in the web browser memory, and not on disk. Not only 

web HTML data and, for reference, are denoted and dis- does this better protect the sensitive values of the "security 

cussed below as Getpage, Authenticate, View Credentials, cookie", it makes it impossible for the browser to be 

Change Credentials, View Label, Change Label, Change restarted and automatically already have its credentials 

Password, Password Form and Logout. These security CGIs 5 established with the web server. It is also preferred to 

will be discussed in turn in connection with FIGS. 2, 3, 5, 6, provide a Secure Socket Layer (SSL) encryption 450 as part 

7, 8, 10, 11 and 12, respectively, and in relevant combina- of the web browser interface to prevent theft of a valid 

tions in connection with FIGS. 4, 9 and 13, respectively. cookie b ? a " network sniffer". As will be described below, 

™™*ijjt^ • a Logout security CGI is also provided to limit duration of 

Re fernng now to FIGS. 2, 3 and 4, the Getpage security °- tn , r _ , „ r , ^ , . , (k t f 

r>m *ii 4 . a • mr* ■ j- a a - * t u *u c * m lne existence of each valid cookie to that of a session. 

CGI illustrated in FIG. 2 is divided into four phases: the first 10 t. e ^ . . t e * . t . u 

, - in . . ,. , A*** j Therefore, penodic destruction of active cookies through 

phase 210, including steps 211, 212, 213 and 214 provides web serve / administrative action ^ ^ iUsd l0 ^ns in 

preliminary support for determining whether the user is which ^ user faas lect6d tQ ^ 

already in possession of a security cookie. The second phase ~ >jC „ . . , « , 

220, including steps 221, 222 and 223, constitutes the ) &c f\' "J ; h ° w ° m Ae ^'T re P res f nted b V 

security filter function which is the main task of the web 15 F' GS - 2 *f 3 - both the Getpage and Authent.cate functions 

server trusted services broker (TSB). A third phase 230, ^ m ^ pa !f mg ,h ' UpU , t 1 V R ^ t 1 ° ^."j?* fi T ""I* 

including steps 231, 232, 233 and 234, provides the setup for bl ° wser ' ^lus rated in 211, 311. The ' additional path 

-j-„ „ ,u. .• .~ j p t t i Via information , or extrapath part of the URL denotes which 

providing a user authentication, and a fourth phase 240, „ •■/.,., ... „™ - 

- 0 ;°„ ct „ • „ fi „. pla „ „ „„„ ,„ „;,. „. „„„ configuration data file is to be accessed by the CGI for 

comprising step 241 is a nnal step common to either phase , ... ,. .,.„, ., . ' , 

220 or 230 20 knowing tne cookie name, H TML document location, and 

_ _ ' , „. , . . omer processing parameters such as security policy (e.g. 

The first phase 210 determines if the client has a security MAC or DAC), the location of the registry, and other flags 
cookie and, if so, provides for the creation and necessary , hat affect detailed p rocess ing (212, 312). The Getpage 
manipulations of the security cookie "surrogate credential" fimction additionally gets the requested HTML page from 
into an actual credential such as a user or group identity. The the parameter list poition of lhe URL (211) . The Authenti- 
cation of the actual credential from the security cookie cate receives autheDlication information such as 
provides discrimination in regard to access authorization to username pasS word as typed by the user doing a logon, 
whatever degree may be desired. The second phase 220 b vimje of the web form ; tQe da , a via the pj-pyp 
retrieves the desired information and assembles the HTML P0ST protocol instead of using lhe URL parameter Ust> K 
page to be returned to the user, taking account of compari- as t0 betler mde this sensitive authentication data 311). 
sons of security labels . which may be freely embedded in the Addi[ional fidds from ^ wnfi ^ d ^ 
data in comparison with the actual credentials derived from showQ in 2U ^ 3n have t|)e fo „ owi m * ani For the 
the security cookie ,to filter the information in a fine-gramed Q functi ^ TSB Qeader » ioQ d * termines 
manner In dm ; latter regard, as will be discussed in greater whether (he addi , iona , h x , Unks in y of ch 
detail mow, me particular ML page assembled and mE credentials 

or password, or loeeine out, appear exclu- 

transmitted on any particular execution of the Getpage CGI ^ at ^ ^ M ^ * c ^ Qr Qmer 

script depends on the credential values derived from the ion of ^ format of ^ user 0f ^ { ^ 

security xookie^The third j)hase 230 prepares for a new user id ^ Qames deDote J ^ tQ 

authentication described below. displfly at the ^ afld boUom Qf ^ ^ L tf spedfic 

Before proceeding to a detailed discussion of FIGS. 2 and ^ re gi str y controls have been enabled. Neither of these fea- 

3, it should be noted that the data flow diagrams represented tures j s particularly important to the invention, and could be 

by FIGS. 4, 9, and 13 differ from the arrangement illustrated omitted without significant drawbacks. For the Authenticate 

in FIG. 1 in one facet. Although these three data flows are function, a "shortcut" option dictates whether, upon a suc- 

of a lower, more detailed level than FIG. 1, the functions of ceS sful authentication, the browser is given a reply that 

the web server and CGI logic as denoted by numbers 50 and 45 denotes the success, but to which a user must click a 

90 in FIG. 1 are merged into one box in these more detailed hypertext link to get the originally requested and filtered 

descriptions, because the native web server functions simply HTML page, or whether upon success the requested and 

serve as a middleman module between the CGI scripts and fi i tered page ^ returned immediately, without the interme- 

the web browser. diate reply. Although the shortcut is often viewed as a 

Dynamic storage (also subject to administrator control) of 50 convenience and as having better human factors, it also 

cookie mappings including user names, current credential, could be omitted without departing from the principles of 

credential range and the last requested HTML page is the invention. 

provided in storage 460. It should be noted that the "ere- The Getpage function of FIG. 2 continues with retrieval 

dential range" stored under both 460 and 470 contain the 0 f any cookies it was sent. In a CGI, this is performed by 

same information. The reason for the duplication is that once 55 reading an environment variable that the native web server 

a user is authenticated, the desire is to no longer reference sets (213). Cookies are provided in the form of name-value, 

this information directly from the TSB Registry 470 but Step 214 determines if any of these cookies has a "name" 

rather from the cookie mappings 460, TSB configuration that matches the name denoted by the configuration file. If 

data is stored at 430 and is read by any CGI script during so, the "value" is used as a lookup key to see if the server 

initialization and contains the locations of secured HTML 60 already has mapped credential information to it (FIG. 4, item 

pages or other articulations of secured data stored at 420. 460). If this is also so, then control is passed to item 221 to 

The location of secured data are accessible only through perform the basic document filtering function. If either 

CGI scripts. condition is not met, an authentication is necessary before 

The web browser 30 potentially differs from that shown in attempting to send back filtered HTML pages, hence control 

FIG. 1 by providing for storage of the user's cookie for the 65 is passed to step 231. 

current session. A preferred embodiment of the invention If an authentication is needed, step 231 assigns a new 

assigns no lifetime to the cookie, so that the cookie is only random value to the client and the requested HTML page 
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name is mapped to this value for later retrieval, as illustrated 
at 232. Then, in steps 233 and 234, a "web form" is built for 
transmission (241) to the client that requests user identifi- 
cation data (e.g. user name and password). In addition, the 
HTTP header of this transaction is supplied a "set cookie" 5 
directive so that the browser echoes back this particular 
cookie value on all subsequent requests. This cookie value 
is only valid during the current browser session and disap- 
pears when the browser is terminated. When the "web form" 
is submitted, the Authenticate function (as illustrated in FIG. 10 

3) is invoked through a corresponding CGI script in accor- 
dance with the invention. 

It should be understood that the cookie thus set is neces- 
sary to carry out the Authentication CGI script and access to 
secured data will not be granted unless the Authentication 15 
process is successful. If the Authentication process is 
successful, the cookie is established as a security cookie 
through having the CGI script map the user identity and 
credentials to the cookie value. This mapping establishes the 
security cookie as a surrogate credential. 20 

Referring now to FIG. 3 and assuming that steps 311 and 
312, described above, have been carried out, a determination 
is made at 313 if a cookie (e.g. security cookie) value was 
included (e.g. sent back to the web server from the storage 
440 of the browser) in the request. If not, an HTML page 25 
"body" is built reporting an anomalous condition (314) most 
likely caused by a user having saved an old AUTHENTI- 
CATE CGI URL as a bookmark, and replaying it back to the 
web server much later before properly trying to authenticate 
via the GETPAGE CGI. A standard HTTP header is con- 30 
structed (323). The header and body can be built in any 
order, and are transmitted to the client/browser (324). 

If, however, a cookie value was transmitted with the 
request, the user name and password is authenticated by 35 
comparison against the data statically stored in the TSB 
registry. If the comparison is not successful, as determined 
at 316, the process branches to 317 to build an HTML body 
indicating a failed logon and a message for retry, preferably 
in the form of a hypertext link to re-enter the Gelpage ^ 
process of FIG. 2. 

If the authentication has been successful, the user is 
informed and provided with a link to continue (411 of FIG. 

4) and it is determined at 318 if an entry for the security 
cookie value exists in dynamic cookie mapping store 460. 45 
This will generally be the case if the Authenticate process 
was preceded by an initial Getpage request in preceding 
steps 231, 232 of FIG. 2. If the mapping does not exist, an 
HTML "body" is built, reporting an anomalous condition 
(319) most likely caused by a user having saved an old 50 
AUTHENTICATE CGI URL as a bookmark, and replaying 

it back to the web server much later before properly trying 
to authenticate via the GETPAGE CGI. A standard HTTP 
header is coastructed (323). The header and body can be 
built in any order, and are transmitted to the client/browser 55 
(324). 

If dynamic mapping does exist, user credentials are 
obtained from the TSB registry as a function of the supplied 
user name. The user name and credentials arc associated 
with the security cookie value and the identification of the 60 
requested HTML page is obtained from dynamic mapping 
memory 460. If the "shortcut" option was configured to be 
off, a "body" is built to tell the user that authentication was 
successful. A hypertext link to the GETPAGE CGI is 
included, so that when the user gets the reply, the user must 65 
click the hypertext link to receive the first filtered page 
(321). If the "shortcut" option is configured to be on, this 



intermediate reply is skipped, and the filtered data is sent 
immediately (322). The logic of 322 in FIG. 3 and the logic 
of 223 in FIG. 2 are the same. When the shortcut is on, a user 
that sees filtered data immediately after having supplied 
authentication data knows the logon succeeded, otherwise 
an error panel would have been returned instead. 

To recapitulate with reference to FIG. 4, a user makes a 
request 401 to the invention to retrieve a filtered page. When 
the client as yet has no valid cookie, the invention detects 
this, assigns a random cookie value, and adds a new entry to 
the dynamic mappings with this value as a lookup key, and 
maps the requested HTML page (410) to this value. The 
reply sent back to the browser (403) is a web form request- 
ing the user type authentication information. This reply also 
includes the "set cookie" operation that endows the browser 
with the cookie value. 

When the form is returned (405) with the user name, 
cookie value and password in the next request, the user name 
and password can then be compared against registered user 
information statically stored in the TSB registry in the 
performance of step 315 and retrieved as indicated at 408 in 
response to detection of a cookie value (406). The compari- 
son is typically one based on cryptological methods if 
authentication is password based, as indicated at 407. After 
a successful authentication, the other fields of the dynamic 
mapping are established (409) including the user name and 
the credentials data retrieved from the registry. This effec- 
tively establishes the "security cookies". The originally 
requested page is obtained from the cookie mapping (410), 
and as shown in the diagram, used to fill a hypertext link in 
the browser reply (411), which illustrates the scenario where 
the shortcut option is configured to be off. If the user clicks 
the hypertext link, this results in a GETPAGE request (412), 
which like all subsequent requests includes the cookie 
information established earlier under 403. 

This invocation of GETPAGE detects the existence of the 
cookie value within dynamic mappings, and can thus infer 
that the user has already performed the authentication 
process, through the fact that the browser is capable of 
supplying a valid known cookie value. GETPAGE thus 
retrieves the credentials information from the mappings 
(413), retrieves the HTML file specified in the URL, filtering 
it in accordance with whether the user's credentials arc 
sufficient to be allowed access to the HTML page, or any 
fine-grained portion thereof, and adding other items to the 
HTML such as images and headers, and returns this filtered 
reply back to the browser (414), as will now be discussed in 
detail. 

Returning now to FIG. 2, after the identification of the 
requested HTML page has been read from dynamic mapping 
memory as shown at 221 (410 in FIG. 4), a standard HTTP 
header is built as shown at 222 and the requested HTML 
body corresponding to the requested HTML page is con- 
structed. In addition to construction of a TSB header and 
optional footer and hypertext links to other CGI scripts (such 
as for password change, logout and other secure CGI scripts 
in accordance with the invention which will be described 
below), the requested HTML page is read off disk and 
scanned for fine-grained and page security labels. 

If a page security label is found, the label is compared 
with the user's mapped credentials. If the page security label 
exceeds the authorization indicated by the user's credentials, 
an "access denied" page is constructed and returned to the 
client/browser. Otherwise, the user's credential is compared 
against fine grained security labels of the form: 
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<seclabel LABEL> [other HTML constructs] 
</scclabel> 

where LABEL is a string representation of the fine grained 
label (e.g., in a DAC access policy, it might be an access 
control list like "engineer: rw, finance:^', and in a MAC 
access policy, it might be "TopSecret/Nato".) The "[other 
HTML constructs]" between any <seclabel> and </seclabel> 
pair define the HTML data the label protects. The preferred 
form of the invention does not support nesting of labels; in 
fact, the invention deems a file to be mislabeled and, hence, 
not retrievable to browsers under any circumstances if it 
encounters two <seclabel> structures without an intervening 
</seclabel>, or vice versa. Nevertheless, as can be 
appreciated, imbedding of such fine-grained label constructs 
allows great latitude in controlling access to portions of a 
single, static HTML page, even without nesting, which 
would greatly complicate the filtering algorithms. 

Data in the HTML page can thus be filtered against the 
user's credentials and only data and links to which access is 
authorized is presented to the user as depicted at 223. In the 
same process, hypertext links to which the user is granted 
access are converted to an appropriate Getpage CGI func- 
tion. For example, the invention allows the WebMaster or 
other web administrator to create these secured web pages 
such that if a hypertext link refers to another user selectable 
secured page, the web administrator simply provides the 
relative name, and the invention converts the hypertext link 
to an appropriate Getpage CGI URL name format during the 
filtering process. Note that just because the user has access 
to the hypertext link in one filtered page does not guarantee 
anything in regard to whether or how much access a user has 
to a page that the user chooses to retrieve via clicking the 
hypertext link. This filtering process is considered to be the 
principal function of the trusted services broker (TBS) in 
accordance with the invention. 

However, to provide a preferred environment for the user 
and for manipulations or operations using other CGI scripts 
in accordance with the invention and which will be 
described below, it is preferred as a perfecting feature of the 
invention to provide unobtrusive marks (e.g. small graphical 
image file (GIF) images such as low contrast dots in a 
display) of the text at the location in the text of any view able 
fine-grained labeled data (e.g. at the location of the HTML 
label structure), one image denoting the start of the labeled 
data, and another image denoting its end. The starting GIF 
image may be clicked to invoke another CGI function to 
view the label contents. 

More specifically, additional CGI scripts are preferably 
provided to allow the user, if authorized, to view or change 
passwords, security labeling, credentials and to perform a 
logout. These controls are preferably presented, to the extent 
authorized to a particular user, within a so-called TSB 
header, or header and footer, that are placed before and after 
the filtered HTML data. A logout CGI script would be of 
particular value if the web browser machine were open to the 
public, and the web browser left running as multiple people 
used the system in turn. Labeling CGI scripts are important 
if it is important to let people see the label value of 
fine-grained sections for which they have access, and to 
perhaps change those labels within the access control rules. 
Credential CGI scripts are important if the access policy 
grants the user a range of potential values, which can be 
changed, perhaps to satisfy a "least privilege" policy. Pass- 
word CGI scripts are almost always important since it is 
generally important for users to change passwords on occa- 
sion. 

Referring now to FIG. 5, the View Credentials CGI script 
will now be discussed. The purpose of this CGI script is to 
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allow the user to display current credentials corresponding 
to the current level of access. The user may wish to alter the 
level of access authorization at which the system is accessed 
in view of the current need to know and/or other circum- 

5 stances such as the presence of other persons. No parameters 
are required for this CGI script since the user's credentials, 
for which the security cookie is a surrogate, is sufficient to 
the retrieval of a suitable form or menu. 
Specifically, like the Get page and Authenticate security 

ao CGI discussed above, the View Credentials CGI begins by 
parsing the URL for additional path information 501 and 
reading the TSB Configuration file for a location (e.g. Ea 
virtual web site) for a web cookie name, TSB registry 
location, secure HTML file location and security policy 

is (MAC or DAC) at 503. Then, cookies are obtained by 
reading the CGI environment variable setup by the web 
server (505). If the web cookie name is not found, or if the 
value associated with the cookie is not mapped to any user 
credentials within the dynamic mappings, then an anomaly 

20 message is built and transmitted with a standard HTTP 
header as indicated at 509, 511. If the mapping exists, the 
CGI builds a web form displaying the user's current cre- 
dentials. The form is built to allow the user to submit 
changes to the credentials within their allowed range. The 

25 "submit" button (or any similar interface) is built so that if 
clicked or otherwise selected, the Change Credential CGI 
would be invoked. These operations are also depicted in data 
flow segments 901-903 of FIG. 9. 

Referring now to FIG. 6, the Change Credential security 

30 CGI will now be discussed. This program executes the 
"submit" option for making changes in the credentials 
discussed above. 

Steps 602 and 604 are similar to steps 501 and 503 of FIG. 
5 except that different and additional information is 

35 received. More specifically, since the View credentials pro- 
cess of FIG. 5 is invoked via a hypertext link (depicted at 
901 of FIG. 9), only the additional path information string 
transmitted in response to a hypertext link selection is 
necessary to invoke the process at 501 whereas the Change 

40 Credential process is invoked as the result of submitting a 
form, so it obtains form parameters received per the "HTTP 
POST" protocol (602) as well as having the additional path 
information from the URL. Change Credential obtains more 
information from the configuration file, namely the shortcut 

45 option and TSB header options (604). Steps 606, 608, 610 
and 612 exactly correspond to steps 505, 507, 509 and 511 
of FIG. 5. 

If the user identity and credentials are currently associated 
with the security cookie retrieved at 606, as determined at 

50 608 (905 of FIG. 9), the user's valid credential range is 
retrieved (610) from the static TSB registry 470 as depicted 
at 906 of FIG. 9. The altered credentials from the web form 
transmitted by the client/browser are compared with the 
user's authorized credential range at 612. If the submitted 

55 change is not within the authorized credential range, an 
HTML body message is built 614 to inform the user that the 
submitted change is disallowed. This message preferably 
also includes a Getpage hypertext link to allow return to the 
last page previously viewed. 

60 If the submitted change is within the user's credential 
range, as determined at 612, the current credential is 
changed in dynamic mapping memory 460 as depicted at 
616 of FIG. 6 and 907 of FIG. 9. The identity and location 
of the data in the last displayed page is retrieved from 

65 dynamic mapping memory 460 as depicted at 908 of FIG. 9. 
Then, preferably, the process behaves according to a 
configurable "shortcut" option. If the shortcut is "ofT, the 
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HTML body built in 620 is a message indicating a successful tests of step 812 are successful, the TSB registry 470 is 

credential change, including a hypertext link to GETPAGE, updated with the new (encrypted) password (816, 916) and 

which the user can click to get back to the previously visited an HTML body message denoting success and a hypertext 

filtered page (which will now be filtered differently per the Get page link is built at 818 and transmitted at 820, 918. For 

changed user credentials.) If the shortcut is "on", box 622 5 Change Password, explicit visibility as to a successful 

will behave like box 224 of FIG. 2, reading the previously chan 8 e * deemed important enough so as to effectively 

access HTML file, performing label filtering and the other cause the lo S ic t0 acl as if lhe shortcut option were "off', 

label imaging and TSB header supports, the result being that Hence ' the ^J^ 9 ^ HTML P a & e is ret ' ieved from the 

after a successful change of credentials, the user is imme- mappings (917), and an HTML body built in 818 is a 

diately given back the last page viewed, this time filtered io u^^^v^^S^T^ change include a 

with the new credentials The change credential security h yP ertexl hnk t0 GETPAGE, which the user can click to get 

wuh the new credentials Jne change credential security back tQ me previousl visited filtered 

CGl^ conipletcd. in either case by building a standard The view label, Change label and Loiout security CGI 

HTTP header and transmission of the header and HTML are Ulustraled at mGSi f 0 u ^ 12 respectively and the 

body to the client/browser, data flow for these processes is depicted in FIG. 13 in the 

Referring now to FIG. 7, the Password Form CGI will 35 same manner as for other security CGI discussed above. The 

now be discussed. This CGI, along with the Change Pass- view label and Change label security CGI allow the manipu- 

word CGI of FIG. 8, allow users to periodically change their Jation of security labels within a secure HTML page at a 

passwords, as stored and managed by the CGI within the fine-grained level. These two CGI scripts perform an analo- 

TSB registry (item 470 in FIG. 4.) These CGI provide the gous function for security labels as the View credentials and 

ability to change a password via web forms, with a similar 20 Change credentials CGI performed for credential manipu- 

look-and-feel to the other web forms in support of labels and lation discussed above. However, these two CGI scripts 

credentials that other CIGs of the invention support. functionally differ from other security CGI discussed above 

As with other security CGI provided in accordance with by being related to specific textual data that is displayed at 

the invention, the URL is parsed for additional path infor- particular locations withing the filtered HTML page, 

mation (702) identifying a request for a security CGI and the 25 Therefore, selection of any particular item is preferably done 

TSB. Configuration is read, including the cookie name, TSB graphically with a cursor and a cursor control device such as 

registry location, secure HTML file location and security a mouse, light pen, trackball, touchpad or the like in a 

policy, as depicted at 704. The client's cookie value for that manner well-understood in the art. 

cookie name, transmitted with the CGI request (910) as a Referring now to FIG. 10, the View Label CGI is pref- 

CGI environment variable is then retrieved and a determi- 30 erably invoked by selection of a location in a text string such 

nation is made if a user identity and credentials are associ- as by "clicking" (1301) on a location in a display of text, 

ated with the cookie value in the dynamic mapping memory images, and the like. This action can, for example, be 

460 as illustrated at 708 of FIG. 7 and 911 of FIG. 9. invoked by having the filtered page contain small GIF 

As in security CGI discussed above, if no mapping is images placed wherever viewable fine-grained labels appear 

found, an HTML body message is built (710) to inform the 35 in the HTML, and assigning a hypertext link reference to 

user of an anomaly, failure, administrative error or the like, them, such that if a user clicks on any such image, it invokes 

a standard HTTP header is also built and the header and the View Label CGI function, along with URL parameters 

body sent to the client/browser (714, 912). If the mapping is that identify which page is being referenced, along with 

found to exist, an HTML body is built including a web form which label, identified by a number understood by the CGI 

asking the user to supply a new password at 712 and 40 scripts, within the HTML page which is to be viewed, 

transmitted with a standard HTTP header as also depicted at The View label security CGI request begins by parsing the 

714 and 912. The "submit" button of the web form is built URL for additional path information in step 1002. The 

so that if clicked, the Change Password CGI would be virtual web site is determined from the extrapath informa- 

invoked, as represented in FIG. 8. tion in the URL which determines the TSB. congiguration 

In much the same manner as the View credential and 45 file for reading other parameters including the web cookie 

Change credential CGI discussed above, step 802 of the name, TSB registry location, secure HTML file location and 

Change password CGI is the same as step 702 of the security policy, as depicted at 1004. The client's security 

password form CGI of FIG. 7, except that a new password cookie value sent with the URL is retrieved at 1006 and the 

is received via the "HTTP POST" protocol here (802). Note existence of corresponding mapping is detected at 1008, as 

that if a user typed the new password information but did not 50 before. Similarly to other CGI described above, if such 

submit the form, then this Change Password CGI would not mapping is not found, an HTML body message is built at 

be invoked. The user could have simply hit the "Back" 1010 and returned with a header including a hypertext link 

button of the web browser to cancel any attempt to change at 1020. 

password. Steps 804, 806 808, 810 and 820 are identical to If the mapping is found, the HTML page is scanned for 

the corresponding steps of the password form CGI described 55 the selected label number as shown at 1012, 1302 and, if the 

above and provide a reply to the client/browser including a page and label are not both found, an HTML message body 

hypertext Getpage link to continue if the mapping of ere- is built indicating "file not found", "label not found" or the 

dcntials with the security cookie value (detected at 914 of like at 1016 and transmitted with a standard HTTP header at 

FIG. 9) is not found. 1020. If the page and label number are both found (1303), 

If the mapping is found at 808, it is determined at 812, 915 60 the mapped credential range and label value are retrieved 

if the old password cryptographically matches the value (1304) and used to build an HTML body consisting of a web 

known in the registry, and the new password is valid. (A form, that displays the current label via checkboxes and 

preferred embodiment of the invention would make checks choice menus, such that the choices available but not 

on the new password such as minimum length, does not selected are within the user's credential range. I.e., the form 

equal the previous password, contains a number, etc.). If not, 65 is built to allow the user to submit changes to the label within 

an error message with a hypertext link to retry is built at 814 the user's valid range. The "submit" button is built so that if 

and transmitted with a standard HTTP header at 820. If the clicked, the Change Label CGI would be invoked. 
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As with other security CGI discussed above, the Change 
label security CGI in accordance with the invention, illus- 
trated in FIG. 11, is executed upon activation of the "submit" 
arrangement (1306). Again, steps 1102-1116 and 1130 arc 
identical to corresponding process steps 1002-1016 and 5 
1020 of FIG. 10 except that the desired new label is captured 
at 1102 and shortcut and TSB. Header options are read at 
1104. If the mapping for the security cookie is found at 1108, 
1307 and both the page and label are found at 1114, 1308, 
it is determined at 1118, 1309 whether or not the user is 10 
granted "change label permission for that label. (The change 
label permission is determined according to the access 
policy in force. For a DAC policy, there should be a unique 
permission bit in the ACL-style label to denote it. A MAC 
policy can allow a label change as long as the current label 15 
is within the user's valid MAC range, or, the MAC policy 
might mark users as having upgrade/downgrade privilege.) 
If not, an HTML body message is built at 1120 indicating 
that change label permission is not authorized and the 
message is transmitted with a HTTP header at 1130. 20 

If Change label permission is authorized, the selected 
label number is replaced (1110, 1310) with the new label and 
the HTML page is rewritten to disk. The Change label 
process concludes with steps 1124-1128 including execu- 
tion of a shortcut option branch (both branches including 25 
filtering for redisplay 1311 of the last HTML page) such as 
those of FIGS. 3 and 6 which need not be discussed further. 

Referring now to FIG. 12, the Logout security CGI will be 
discussed. This CGI script is preferably invoked by a 
selection from the TSB header and serves to delete the 30 
client's cookie value from the server's dynamic mappings 
(1212, 1315) and can do so without termination of the 
browser. (After a logout, the client still has the cookie whose 
value has been deleted but the cookie is no longer recog- 
nized by the server.) This is particularly useful, as alluded to 35 
above, when the same terminal and/or browser is to be used 
in rapid succession by different users where termination of 
the browser to destroy the security cookie would be unac- 
ceptably time-consuming. Steps 1202-1210 and 1220 are 
similar to corresponding steps in the flow charts for CGI 40 
scripts shown in, for example, FIG. 7 or 10 and need not be 
further discussed. If the mapping for the security cookie 
value is found (1314) at 1208, it is removed at 1212 (1315) 
and an appropriate HTML body message is built at 1214 and 
transmitted (1316) with an HTTP header. 45 

In summary, of the above discussion, the invention pro- 
vides flexible, fine-grained security to the level of a data or 
HTML element (e.g. word, number, image, hypertext link 
and the like) in a manner compatible with Internet protocols 
and procedures by providing a secure but easily used mecha- 50 
nism for establishing a security cookie as a surrogate cre- 
dential for a single session (and destroying the security 
cookie by logout or browser termination) under the control 
of a CGI function that authenticates users according to a 
registry that defines users and their valid credentials. 55 
Labeled HTML files are secured by the articulation of 
memory as established by the configuration file (e.g. such as 
forming a virtual web site) such that secured HTML files, 
plus any configuration files or registry files used by a "virtual 
web site", are only accessible through the inventions' CGI 60 
scripts and not accessible by the native web server software. 

The security CGI scripts are invokable by the web server, 
but cannot be altered in any way by the web server. 
However, as with all software that enforces security, admin- 
istrative care must be taken so that only those humans 65 
endowed with trusted administrative authority have the 
ability to access these entities directly, such as for installa- 
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tion and maintenance. Fine grained security as well as 
accommodation of different security policies (e.g. MAC 
and/or DAC) is realized by filtering the HTML page in 
accordance with dynamically stored credentials while build- 
ing an HTML body message for transmission. 

Once a randomly assigned cookie value has been assigned 
to a client/browser, access to secured information (filtered in 
accordance with access credentials) continues for the dura- 
tion of the session until the cookie is destroyed by logout or 
browser termination in a manner substantially transparent to 
the user. The system in accordance with the invention need 
only be installed at the web server and enhances browser and 
server functions by allowing different security policies for 
any given virtual web site, imbedding of fine-grained secu- 
rity labels and alteration of passwords and credentials to be 
supported. 

While the invention has been described in terms of a 
single preferred embodiment, those skilled in the art will 
recognize that the invention can be practiced with modifi- 
cation within the spirit and scope of the appended claims. 

Having thus described our invention, what we claim as 
new and desire to secure by Letters Patent is as follows: 

L A method of limiting access to information stored in 
HTML files on a fine-grained basis and independent of 
HTML contents, accessible by a web server through a CGI 
script, according to security label constructs imbedded 
within web -server stored HTML, said information compris- 
ing a definition of HTML label structures recognizable by 
said CGI script, said method comprising steps of 

dynamically storing at said web server a mapping of a 
web cookie value to user credentials retrieved from 
CGI accessible registry storage, thereby establishing 
said web cookie as a security cookie in said mapping, 
creating a set of said credentials by prompting a user for 
authentication information, validating said authentica- 
tion information against user information retrieved 
from said CGI accessible registry storage, performed in 
response to a request for retrieval of a stored HTML file 
that was not accompanied by a recognized web cookie 
name and value as contained within said mapping, 
retrieving said stored HTML file in response to a request 
from a user accompanied by said security cookie value, 
filtering said stored HTML file with said CGI scripts as a 
function of security label constructs embedded in the 
HTML file in accordance with a comparison to said 
user credentials associated with said security cookie 
value to form filtered information in the form of 
standard HTML in accordance with said HTML label 
structures, and 
returning said filtered information to said user. 

2. A method as recited in claim 1, including the further 
steps of 

supporting credential formats corresponding to any of a 

plurality of modes of access control with a definition 

within CGI accessible registry storage, 
storing credential information in forms which support said 

CGI accessible registry storage definitions, and 
providing said HTML security label structures which 

correspond to said CGI accessible registry storage 

definitions. 

3. A method as recited in claim 2, wherein said credential 
formats include a discretionary access control mode and a 
mandatory access control mode for defining user credentials 
and HTML embedded security labels. 

4. A method as recited in claim 1, wherein said HTML 
label structure identifies text within said HTML file and 
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provides authorization control for access and alteration of 
the HTML label structure by the user. 

5. A method as recited in claim 1, wherein said HTML 
security label structure includes a coarse-grained option 
controlling access to the entire HTML file. 5 

6. A method as recited in claim 1, wherein said web 
cookie value is set without specification of a lifetime of said 
web cookie value, whereby said web cookie value is 
destroyed upon termination of a web session in which it is 
set. 10 

7. A method as recited in claim 1, wherein said request 
including said security cookie is encrypted. 

8. A method as recited in claim 1, including the further 
step of 

adding function information to said filtered information to 15 
be sent to said user. 

9. A method as recited in claim 8, wherein said function 
information includes a hypertext link to a CGI program 
which supplies a web HTML form containing current cre- 
dentials and allows change of said current credentials. 20 

10. A method as recited in claim 8, wherein said function 
information includes a hypertext link to a CGI program 
which supplies a web HTML form which allows change of 
user password of said user. 

11. A method as recited in claim 8, wherein said function 25 
information includes a hypertext link to a CGI program 
which provides a logout function. 

12. A method as recited in claim 8, wherein said function 
information includes image information indicating the loca- 
tion of a label in text of said HTML file. 30 

13. A method as recited in claim 8, wherein said function 
information includes a hypertext link to a CGI program 
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which allows change of said HTML label structures in 
accordance with user credentials. 

14. A method as recited in claim 1, wherein said CGI 
scripts convert HTML hypertext links to a CGI format to the 
web client and wherein said filtering step includes the 
further step of converting said hypertext link to a CGI URL 
upon selection of said hypertext link by a user to invoke 
further CGI filtering functions such that accessing other 
HTML though such hypertext links will be subject to the 
same CGI script security label filtering mechanism, whereby 
a web administrator may include non-CGI hypertext links 
within the security labelled HTML. 

15. A method as recited in claim 1, including the further 
step of 

validating user passwords using cryptographic password 
representations within said CGI accesssible registry. 

16. A method as recited in claim 1, wherein said CGI 
scripts are configurable to return enhanced information to 
the user, said enhanced information including an indication 
of label existence and icon-visible hypertext links allowing 
view or change of label information in the web page in 
accordance with user credentials. 

17. A method as recited in claim 8, wherein said CGI 
scripts are configurable to return enhanced information to 
the user, said enhanced information including an indication 
of label existence and icon-visible hypertext links allowing 
view or change of label information in the web page in 
accordance with user credentials. 

* * * * * 
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